@jimp said in Modify .tcshrc: https://redmine.pfsense.org/issues/14746 JUst found this : I just pushed a commit that implements "local" versions of .profile, .shrc, and .tcshrc which are, respectively: .profile.local, .shrc.local, and .tcshrc.local in the user's home directory. Great !! Cool !! Now I can finally use 'll' as an alias for "ls -al" just by creating a small " .tcshrc.local" in the root folder. Thanks !

@viragomann Thank you very much for the tip, I did what you told me and it worked

@ukhobo I too have a BT/EE ISP connection and would love to be able to place their hub used for VoIP behind my pfSense router. Someone on the thinkbroadband forum managed to get around it using a custom Asus router firmware (probably similar to OpenWrt). If there was a way to run a cron job on pfSense that extracts the changing Host-Uniq, store it into a file or some kind of varible and then use this to dynamically update the Host-Uniq field within pfSense that'd be one way to go about it. https://forums.thinkbroadband.com/fibre/4664092-bt-fttp-with-digital-voice-alternative-to-smart-hub-2.html?fpart=7#Post4670157 Did you ever find a solution to this? I persoanlly will be carrying on using pfSense behind my BT router unless someone has a solution.

@yobyot said in Stuck on CE 2.7 with a php error causing available packages to be blank.: I've never had the next release step on the current release Your issue was as noted above. However addressing this comment, it's been a longstanding issue in pfSense. See https://redmine.pfsense.org/issues/10464 but especially note the last note: "The update check process has changed recently (available in 23.09 and CE dev currently). Now relevant repos are checked for updates without affecting the current repo itself. This avoids automatically updating (e.g. pkg) against a repo that doesn't have compatible packages (hence no more pkg dynamic library errors)." The fix is targeted to 2.8.0 per the top of the page. PS - hooray!

VirgnMedia terminology is often different from other ISP's around the world & can be confusing. Default mode = NAT router. "Modem Mode" = Bridged. DMZ is only available in router mode, hence why it works. In Bridge mode, you can only have one device connected (and the hub disables its WiFi). Earlier VM Docsis CM's (Hubs 3 & 4) always used port-1, but some users say the 2.5Gig port can be used. although this is unconfirmed. First device will grab the bridge IP, so make sure there's only PfSense connected. Everything else in your network needs to be on the PfSense LAN side. BTW, count yourself lucky. VF-Ziggo users with same hardware don't have bridge mode available !!

Just remember (ask me how I know!) that unlike a VM snapshot once you default or otherwise break a BE you cannot roll it back. You can only switch to a different BE. So if you want to have that point remain available be sure to create a new BE snap each time before you run tests etc. Steve

The pfSense Quagga package was deprecated in 21.02/2.5. The last version that shipped in 2.4.5 was 1.2.4_7. Why are you asking this here? Steve

@SteveITS I was going to suggest something similar but as I have not tried to reverse engineer the configuration file I was unsure how hard that is. To do it I would compare a reset to default configuration file with the existing configuration file.

Thanks everyone putty and Windows 11 fixed it with the correct usb driver [image: 1701297532801-screenshot-2023-11-29-143357.png] Got access to the boot environments now. I can't get some packages to with with ARM for 23.09 I keep getting completely locked out and having to go back. That fixed it.

@stephenw10 I really don't know myself.. But i tried it by upgrading from 2.6 which works fine.. and clean install.. both fail. I set it this way.. CMIIW.. 2 WAN, each WAN's interface i set the default gateway to ISP1 & ISP2. LAN interface, i set it to none, or L3 switch doing intervlan routing inside ( no queue mgmt at all at L3 switch ) Turned off NAT. In Settings - Routing - I set the default gateway either ISP1 or ISP2, or automatic. It just works everytime with 2.6.. i even reinstall the 2.6 as well for testing purpose.

Ok, so you only see issues with the RDP traffic? When WAN1 is down you still have general connectivity via WAN2 from clients behind pfSense? Do you see the RDP traffic arrive at the remote firewall? Do you see states created for it in pfSense?

@Vollans You're right. Some (most ?) registrars will handle Dyndns if you have a domain name with them. Nothing wrong with Floudflare

It does and in fact actually I see the error from repoc in your initial output. Send me your NDI in chat and I'll check it. Steve

@leres said in Cannot boot 23.05.1 (sg-2100 w/zfs): expect partition size was not an issue. Glad you got it working. The EFI size wasn't an issue if it had ZFS already and/or was newer than early 2022, IIRC. I just mentioned it because we had started planning to reinstall all those 2100s. :-/ We had similar experiences with two clients' 2100s where installing from the same USB stick was not stable (second boot/restart fails, boots up and installs packages then drops offline, etc.) and simply using a different USB stick to do the install has worked fine since then (this past spring). Very strange but seems to be the stick...which we tossed. ref: https://forum.netgate.com/topic/180755/23-05-firmware-upgrade-crashed-a-3100-and-an-1100/ https://forum.netgate.com/topic/180432/certificate-verification-failed/ 23.05.1 was supposed to have fixes already though for those threads.

@stephenw10 thanks, will try

@stephenw10 Looking forward to some clarity. Thank you!

Add pass rules for for each specific IP that needs to access that port. Add a block rule for that port below it for everything else. I would use an alias for the source IPs that need it myself but you could just add separate rules for each device. Why don;t you want to use aliases? Steve

@tom__w How exactly are you scanning.. here is theory.. So your pfsense network is say 192.168.100/24 and your client say 192.168.100.42 for example you say hey scan for 192.168.68.0/24 this traffic since not on the 192.168.100 network would be sent to pfsense say looking for 192.168.68.100 as one of the IPs.. Pfsense says well shoot, I don't have a 192.168.68 network attached to me, send it out my default gateway - your ISP.. Your isp may very well have devices on its network in this rfc1918 space 192.168.68, which could in turn answer say a ping.. So no they are not your devices - they are some devices out on your isp network. edit: example of this... Somewhere in my ISP network 10.0.0.1 answers C:\>ping 10.0.0.1 Pinging 10.0.0.1 with 32 bytes of data: Reply from 10.0.0.1: bytes=32 time=39ms TTL=249 Reply from 10.0.0.1: bytes=32 time=36ms TTL=249 If I traceroute to it C:\>tracert -d 10.0.0.1 Tracing route to 10.0.0.1 over a maximum of 30 hops 1 1 ms <1 ms <1 ms 192.168.9.253 2 11 ms 11 ms 10 ms 209.122.32.1 3 18 ms 12 ms 11 ms 216.80.79.9 4 37 ms 36 ms 38 ms 207.172.18.134 5 36 ms 36 ms 38 ms 207.172.19.124 6 36 ms 37 ms 53 ms 207.172.19.91 7 38 ms 36 ms 41 ms 10.0.0.1 it is somewhere on my isp network, or my ISP network is routing rfc1918 outside their network when they shouldn't But looks to be connected in their network somewhere, if I resolve the IPs in my trace 1 <1 ms 1 ms 1 ms sg4860.local.lan [192.168.9.253] 2 12 ms 13 ms 19 ms c3-0.rol-e6k1.nape.il.cable.rcn.net [209.122.32.1] 3 11 ms 11 ms 11 ms static.rcn.com [216.80.79.9] 4 40 ms 36 ms 38 ms hge0-0-0-7.core2.chgo.il.rcn.net [207.172.18.134] 5 36 ms 35 ms 35 ms hge0-0-0-4.core1.lnh.md.rcn.net [207.172.19.124] 6 56 ms 36 ms 38 ms hge0-0-0-0.core1.phdl.pa.rcn.net [207.172.19.91] 7 59 ms 35 ms 38 ms 10.0.0.1 Looks like the device is some core router in the Philadelphia PA location. or attached to it, could very well be say a loopback address on this device? It is not uncommon to see rfc1918 in a trace through your ISP network, when some devices is setup to answer from loopback. Or even actual interface IP in their network - nothing saying an ISP can't use rfc1918 space as transit networks in their network. I normally run this rule as outbound floating rule to prevent such things. Just being a good netizen - there is little reason to send rfc1918 out to my isp. [image: 1701178214588-outboundrfc1918.jpg] I had to disable it to find something out on my isp that was rfc1918 and answered. edit2: hints that is not on your network, if the response time is higher than just a few ms, its prob not on your network ;) Also see the ttl of that ping above its 249, that isn't a local or even 1 hop sort of ttl. If you ping something local the ttl should reflect that there was no hops to get there. Reply from 192.168.9.10: bytes=32 time=1ms TTL=64 Notice when I ping something on another network attached to pfsense Reply from 192.168.3.32: bytes=32 time=2ms TTL=63 See how the ttl has been reduced by 1, this tells me there was 1 hop to get to that device..

Yes, or import it from FreeBSD as they attempted. In either case it has to match exactly the php version.

I wouldn't expect Kea to make any difference there. It is indeed odd that it would only now start to report that. I did wonder if either the max value changed or the logging level but I couldn't see anything obvious indicating either.